Virtual Memory

Virtual Memory

address spaceIn general, each UNIX process has its own address space. The process sees the address space as a continuous range of memory locations containing the process's code, data, and other resources.

The composition of the address space, and the methods by which a process can share it with other processes, are covered in Chapter 4, "Managing Virtual Memory in a RealTime Program."

page sizememory:virtualvirtual memorymemory:page sizeThe IRIX kernel manages each process's address space as a set of pages. All pages are the same size in one implementation of IRIX. (The page size is 4 KB in 32-bit systems, but larger in 64-bit systems. Programs should always determine the page size dynamically by calling the getpagesize() function.)

virtual memory:page faultpage faultSome or all of the pages that represent a process's address space may be stored on disk. When the process attempts to access a page not in memory, it causes a page fault interrupt. The kernel suspends the process until it can provide the page contents. If the page has defined contents, the kernel schedules a disk I/O operation to load it. If this is the first use of a stack or heap page, the kernel simply creates a page of zeros. In order to make room for the needed page, the kernel may have to invalidate some other page, and may have to save the contents of the other page to the swap disk.

A page fault causes an unpredictable and possibly lengthy pause in the execution of a process. A real-time program cannot tolerate such delays. However, you can have part or all of your program's address space locked into memory, so that a page fault cannot occur.

Translation Lookaside Buffer Updates

TLBtranslation lookaside buffer. <Italics>See<Default Para Font> TLB<$nopage>Virtual addresses are mapped to real memory locations using translation tables kept in memory. For speed, each CPU has a cache of recently-used page addresses, called the translation lookaside buffer (TLB).

interrupt:TLBTLB update interruptUnder certain conditions, kernel code executing in one CPU can change the address space mapping in a way that could invalidate TLB entries in other CPUs. In order to synchronize the TLBs, the kernel broadcasts an interrupt to all CPUs. The interrupt service routine in each CPU purges the TLB for that CPU so it will be reloaded with accurate values. Memory accesses immediately after a TLB purge are slow, while the TLB contents are reconstructed. The TLB update interrupt comes at unpredictable times. A real-time program with tight timing constraints cannot tolerate being delayed this way.

However, when you dedicate one or more CPUs to executing your real-time program, you can isolate your dedicated CPUs from TLB interrupts. (For details, see "Isolating a CPU From TLB Interrupts").